Method using a single authentication device to authenticate a user to a service provider among a plurality of service providers and device for performing such a method

ABSTRACT

A method for authenticating a user to a provider, among a plurality of providers. The method uses an authentication device comprising, for each of provider, a record comprising a pairing key and first data, both as shared data. Provider authentication data comprises a first cryptogram obtained by encrypting said first data with said pairing key. Authenticating provider authentication data is performed at the authentication device by the steps of decrypting said first cryptogram by means of the pairing key stored in one of said records, then comparing the result of this decryption with first data resulting from pairing data stored in said record, if the comparison does not indicate a match, then processing again the previous decryption and comparison steps by using the pairing key of another record until each of said records stored in the authentication device has been processed.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.14/133,219 filed Dec. 18, 2013, which claims priority to U.S.Provisional patent Application No. 61/740,459 filed Dec. 21, 2012, andEuropean patent Application No. EP 12198886.9 filed Dec. 21, 2012. Allof the forgoing are incorporated by referenced herein in theirentireties.

TECHNICAL FIELD

The present invention relates to the field of electronic data exchanges,such as on-line services or e-commerce, requiring a mutualauthentication between a user and a service provider, among a pluralityof providers to which this user has an account. Such authentication isrequired each time the user wants to access to the service of theprovider. In particular, the invention provides a solution for securelymanaging access to a plurality of services (each of them being providedby a specific service provider) by means of one authentication devicewhich avoids the user to retrieve, by himself, both the “user ID” andthe related password which are specific to each account. The presentinvention also refers to the authentication device for carrying out thismethod.

BACKGROUND ART

Thanks to world wide network (Internet), today a common user has accessto a great number of providers suggesting different services such ase-banking, e-commerce, e-booking, or any other electronic services.Service providers can be merchants, organizations or any other entities.Depending on the nature and the importance of certain data exchangedbetween a service provider and a user (also called subscriber), thelatter has to identify himself to the provider by providing a specificso-called “user login” (or “user ID”) and the related password.

As the number of login and passwords to remember is so large, most userseither use the same password everywhere or they write them on a paper inorder to be sure to retrieve them later. These ways of doing do notallow meeting the initial security goals sought by such authenticationwhich can then be compromised. Moreover, to reach a good security level,passwords should be changed, each according to different periods of timeor other rules, for preventing users to use the same passwords during along time period or for several applications.

As example, within the field of e-banking, it is known that the user hasto login to his account by means of an access card and a card readerwhich is independent to the personal computer through which the data canbe exchanged between the user and the service provider. To this end, theuser has to insert the access card into the card reader and enter hisPIN code using the keypad on the card reader. Then, he enters his userID (user login) in the login window on his computer screen. He receivesa number, from the service provider, which be entered on the cardreader. In reply, a one-time password appears on the screen of the cardreader. The user has to enter this password in the password field on hiscomputer. If all data entered both in the card reader and in thecomputer are correct, then the user is successfully authenticated and hegets access to the service of the provider, for instance for performingbanking transactions or for consulting his bank accounts.

However, such a system provides access to one service only. Each serviceprovider needs its own access card which requires a specific cardreader. Moreover, card readers cannot be shared with the access cards ofother service providers. Thus, the user wanting to have access toservices provided by several providers must have, for each serviceprovider, an access card and the related access card reader. This way ison the one hand not convenient for the user and on the other hand notrational from both an economical and ecological point of view.

Therefore, there is a need for improving the management of useridentifiers and passwords required for authentication processes, betweena user and a plurality of service providers to which this user isregistered, by means of an authentication device such as an access card.

SUMMARY

In order to solve the above-mentioned problem, the present inventionaims to provide a solution for managing access to a large number ofservices, each one requiring a specific login and password. Preferably,the latter must meet specific robustness constraints and potentialrenewal intervals imposed by the service provider to minimize piracyrisks. In particular, the invention suggests a method for authenticatinga user to a service provider, among a plurality of services providerseach having a user account for this user. This method uses a singleauthentication device identified by a unique device identifier. Thismethod comprises the steps of:

-   -   transmitting, from the authentication device to the service        provider, an authentication request comprising at least said        device identifier,    -   preparing, by the service provider, provider authentication data        on the basis of pairing data shared by both said authentication        device and said service provider,    -   sending said provider authentication data from the service        provider to the authentication device,    -   authenticating at the authentication device said provider        authentication data; in case of positive outcome, then    -   preparing device authentication data based on any of said        pairing data by the authentication device, then sending said        device authentication data to the service provider,    -   verifying the authenticity of the device authentication data by        the service provider and in case of positive outcome, then        validating the authentication of said user,        wherein    -   said authentication device comprises a provider record for each        of said service providers with whom the user is registered by        having a user account, each provider record comprises a pairing        key KP and first data, said pairing key KP and said first data        being shared with the service provider to which said provider        record refers,    -   said provider authentication data comprises a first cryptogram        obtained by encrypting said first data with said pairing key KP,    -   authenticating said provider authentication data is performed at        the authentication device by the steps of:    -   decrypting said first cryptogram by means of the pairing key KP        stored in one of said provider records, then    -   comparing the result of this decryption with first data        resulting from pairing data stored in said provider record,    -   if the comparison does not indicate a match, then processing        again the previous decryption and comparison steps by using the        pairing key KP of another provider record until each of said        provider records stored in the authentication device has been        processed.

The authentication device is a secure cryptographic device. Preferably,the authentication device is in the form of a smart card (access card).

According to a first embodiment, the authentication device is notconnected to the service provider and data exchanged between the userand the service provider are sent and received by means of a terminal,typically a personal computer within a home environment. Alternatively,the authentication device can be provided with wire and/or wirelesscommunication means (e.g. wireless short range connection means such as

Near-Field Communication) for exchanging data with the service providervia the terminal.

According to another embodiment, the authentication device is acommunication device, preferably a portable computing device such as asmartphone, a tablet computer, a personal digital assistant, a laptop,etc . . . , in which a secure software application has been installed orimplemented for processing the method of the invention. This portablecomputing device can be linked to the service provider either directlyor via the above-mentioned terminal. In the case where it is directlyconnected to the service provider, the authentication device can beprovided with longer range communication means, such as the meansprovided in the mobile phones.

As the authentication device of the present invention is able to manageitself a plurality of account registrations to several service providers(by means of records stored in the authentication device), the userwould simply enters (in the terminal or directly in the authenticationdevice in case the latter is provided with communication means), datarequested by the authentication device.

To further facilitate the login process, the required data exchangedwith the service provider can be automatically handled by theauthentication device if this device is provided with communicationmeans for exchanging data either directly with the service provider orvia a terminal.

The present invention is not limited to the above-mentioned method, butalso relates to the authentication itself. Thus, the invention alsorefers to an authentication device for authenticating a user to aservice provider, among a plurality of service providers, comprising:

-   -   a unique device identifier,    -   a non-volatile secured memory for storing secret and/or shared        data,    -   a user interface for user data input,    -   a display,    -   a crypto-processor for performing cryptographic and logical        operations and for managing functions and all components of the        authentication device.

According to the invention, the memory is organized for storing, in anorderly manner (and within records), data relating to a plurality ofservice providers and the crypto-processor is able to retrieve datarelating to each of these service providers for processing them in adistinct manner.

Other advantages and embodiments will be presented in the followingdetailed description.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention will be better understood thanks to the attachedfigures in which:

FIG. 1 is a block diagram depicting an overview of the main devicesinvolved in the method of the present invention,

FIG. 2 is a schematic enlarged view of the authentication deviceaccording to a preferred embodiment,

FIG. 3 depicts a schematic enlarged view of one of the serviceproviders,

FIG. 4 is a flowchart showing data exchanges between the authenticationdevice and the service provider.

DETAILED DESCRIPTION

Referring to FIG. 1, the latter shows an overview of the system relatingto the method of the present invention. This method aims a mutualauthentication between a user 1 and a service provider 20 among aplurality of service providers. The user is registered to each of theseservice providers, e.g. by means of a user account. Only three providersare represented in the example of FIG. 1 but it should be understoodthat more providers will be generally involved. According to theinvention, this mutual authentication is carried out by means of anauthentication device 10 shown in the figures in the form of a smartcard. In order to authenticate both the user 1 and the service provider20 with whom the user wants to have an access, data 30 has to beexchanged between these two entities. According to one embodiment, sucha data exchange is performed via a terminal 40, typically a personalcomputer within a home environment 45. To this end, the terminal 40 isfirstly provided with at least one communication interface 42, forexchanging data at least with anyone of the service providers 20 througha network 50 (e.g. Internet), and secondly with a software application43 for performing some steps of the present method. According to anotherembodiment, the authentication device 10 could be considered as beingsecure software installed within the terminal 40 or within any othercommunication means such as smart phone, tablet computer, laptop etc . .. . Accordingly, the authentication device 10 could be able to directlyexchange data 30 with the service provider 20. According to a furtherembodiment, the authentication device 10 could be also provided with itsown communication interface 12 for exchanging data with the terminal 40through a wire (e.g. USB) or wireless communication (NFC, Bluetooth,Infrared, etc . . . ), preferably a short range wireless communication.Data exchanged between the authentication device 10 and the terminal 40could be also achieved via an intermediate device (not shown in theFigures) supporting one of these technologies. For instance, such anadditional device could be a card reader in case the authenticationdevice 10 is in the form of an access card.

FIG. 2 is a schematic enlarged view of an authentication device 10.According to a preferred embodiment, this device 10 is a smart cardprovided with a display screen 14 and a user interface 15 such as akeypad. The authentication device is identified by a unique deviceidentifier 11, typically a card number printed on the card. This deviceidentifier 11 could be stored in a memory 16, preferably a non-volatilesecured memory which is also used for storing other data, such as keys,shared data or PIN code (personal identification number). According tothe preferred embodiment, the communication interface 12 is NFCcompliant. The authentication device also comprises a crypto-processor17 for performing cryptographic and logical operations, on the one hand,and for managing all components of the device 10, on the other hand.Cryptographic operations typically refer to encryption/decryptionprocesses, execution of hash functions for providing digests and toexecution of algorithms e.g. for determining challenges or cryptographicresults.

FIG. 3 shows the main components of one of the service providers 20.Each of them is identified by a unique provider identifier 21 andcomprises at least a communication interface 22 for exchanging data(either with the terminal 40 or directly with the authentication device10), a non-volatile memory for storing any kind of data, a database 28for storing a plurality of user accounts 25 belonging to registeredusers benefiting from the services of this service provider and acrypto-processor 27 for managing all the components of the serviceprovider and for performing cryptographic and logical operations.

Referring now to FIG. 4, the main steps of the method are illustrated ina flowchart showing data exchanges between the authentication device 10and one of the service providers 20. The authentication device and theservice provider comprise pairing data 31 which can result (at leastpartially) from a pairing process performed during a registration phasewhere a new account is created for each new user wanting to join a newservice provider. Thus, pairing data may comprise pairing keys and/orany shared data, functions or algorithms known both by theauthentication device and the service provider. At the user side,pairing data are stored in the secure memory 16 of the authenticationdevice, whereas at the provider side, pairing data 31 are preferablystored in the database 27, in particular in the user accounts 25 storedin this database. According to a preferred embodiment, the access to theauthentication device is protected by a Personal Identification Numberknown by the user only. Such a PIN code 13 aims to prevent anyfraudulent use of the authentication device by other persons than thecard owner (mentioned here as being the user). When the user power onthe authentication device, the latter ask him to enter the PIN code. Ifthe PIN code entered by the user does not correspond to a reference PINcode stored in the secured memory 16, then the access to theauthentication device is refused. The user can have for instance threeattempts to enter the PIN code. After entering the PIN incorrectly athird time, the access to the authentication device can be permanentlylocked and the user has to contact the service provider either forreplacing the authentication device or for unlocking it.

The first step of the method refers to the transmission of anauthentication request 32 from the authentication device 10 to theservice provider 20. This request comprises at least the deviceidentifier 11 so that the authentication device can be identified by theservice provider. The device identifier 11 allows seeking into theprovider database 28 to find the corresponding pairing data 31 for saiduser. This can be done through the user account 25, each comprising therelated device identifier 11. In case that the device identifier 11 isunknown (i.e. cannot be found), the authentication is aborted.

Then, the service provider has to authenticate to the authenticationdevice 10. To this end, it prepares provider authentication data 33 onthe basis of current pairing data 31 shared by the two involvedentities. For example, this pairing data can be based on the identifiersof these entities or any other shared information such as timestamps,counters, or random seeds. Such information could be placed e.g. in ametadata field included in the provider authentication data 33 orattached to the provider authentication data while being considered asbeing part of this data 33. Then, the service provider 20 sends theprovider authentication data 33 to the authentication device 10,preferably in the form of a one-time code (OTC) 34.

For each service provider 20 with whom the user is registered e.g. byhaving a user account 25, the authentication device 10 has created, forits part, a provider record 35 in its memory. Once the providerauthentication data has been received, the authentication device mustauthenticate provider authentication data. To this end, it has firstlyto identify one provider record 35 among a plurality of provider recordsstored in its memory, more particularly among at least one providerrecord 35 in the case where the user is not yet registered with morethan one service provider 20. The authentication of the relevantprovider record in the memory of the authentication device is performedon the basis of data comprised in the provider authentication data 33sent by the service provider 20. The authentication of the providerauthentication data is based on the pairing key KP shared between theauthentication device 10 and the service provider 20. In case that theauthentication device 10 is able to find one paring key KP that is ableto validly authenticate the provider authentication data, theauthentication device 10 considers that the provider authentication dataare valid.

Provider authentication data allows the authentication device to pointthe provider record 35 either directly, for instance in the case wherethe service provider is directly identifiable from the provider record,or indirectly, for instance by means of a correspondence table. Such acorrespondence table could list the provider identifiers 21 of all theservice providers to which the user is registered and it could providethe corresponding numbers of each provider record 35 as stored in thememory 16.

In reply to the successful authentication of the service provider, theauthentication device 10 prepares, at its turn to the service provider20, device authentication data 36 preferably based on the pairing key KPshared between the authentication device 10 and the service provider 20.Then, device authentication data 36 is sent to the service provider,preferably prepared in the form of a one-time password (OTP) 37.Similarly, as cited above with reference to provider authentication data33, device authentication data 36 can be based on any of pairing data31, including aforementioned metadata. Once device authentication data36 is received by the service provider 20, the latter can verify theauthenticity of the device authentication data and, in case of positiveoutcome, it can validate the authentication of the user 1.

According to the present invention, the authentication device comprisesa provider record 35 for each of the service providers 20 with whom theuser 1 is registered by having a user account 25. Each provider record35 comprises a pairing key KP and first data. The pairing key KP andfirst data correspond to pairing data 31 as they are shared with theservice provider to which said provider record refers.

Provider authentication data 33 comprises a first cryptogram obtained byencrypting first data with the pairing key KP. First data may result atleast from one of pairing data 31, for instance from the provideridentifier 21, from the device identifier 11 or from a root value knownboth by the authentication device 10 and by the service provider 20.First data can also derive or result from at least one of pairing data31 (i.e. without being directly one of said pairing data), for instanceby means of a shared function having the root value and/or theprovider/device identifier as input. First cryptogram could represent adigital signature by applying a hash function (or any other one-wayfunction) onto first data, in particular one of pairing data (e.g. theprovider identifier 21) to obtain a digest which can be furtherencrypted by means of the pairing key KP. Thus, the first cryptogramcould correspond to the digital signature of the service provider.

The root value could correspond to a secret value that has been storedin the secure memory 16 of the authentication device during itsmanufacturing or at least before it is delivered to the user 1 (thusbefore the first use of the authentication device by the user). Such aroot value could be identical to all authentication devices 10 orspecific to each device 10 or to a certain number of authenticationdevices 10. In any case, the service provider has to be able to retrievethe relevant root value of the relevant authentication device as pairingdata 31, in a similar way as for the pairing key KP. In theauthentication device 10, the pairing key KP is stored in the relevantprovider record 35 given that the pairing key KP differs from oneservice provider to another. The same is done for the root value.However, in the case where the root value is common to allauthentication devices, this root value can be stored as pairing data inthe secure memory 16, avoiding thus to be repeated in each providerrecord 35.

The authentication of provider authentication data can be performed atthe authentication device by the following steps:

-   -   decrypting the first cryptogram by means of the pairing key KP        of one of the provider record 35 to obtain decrypted first data        (e.g. the first provider record stored in the authentication        device), then    -   comparing the decrypted first data resulting with first data        part resulting of the pairing data stored in the relevant        provider record 35 (or with first data stored elsewhere in the        authentication device 10, for instance in the secure memory 16),    -   if the comparison does not indicate a match, then processing        again the previous decryption step by using the pairing Key KP        of another provider record (e.g. the next one) until each        provider record 35 stored in the authentication device 10 has        been processed.

For example, the authentication device 10 seeks to login with the thirdservice provider SP3 and thus has to identify the provider record R3among Rn records stored in its memory. Each of these provider recordscomprises a specific pairing key KP, so the record R1 comprises thepairing key KP1, the record R2 comprises the pairing key KP2, etc . . .In the present example, the pairing key KP used by the service providerfor encrypting the first cryptogram received by the authenticationdevice 10 is KP3. According to an initial protocol, the authenticationdevice 10 knows in advance which kind of data has been encrypted by theservice provider 20. For instance, it knows that the first cryptogram isbased on the encryption of the provider identifier 21. However, theauthentication device 10 has no means to know which service provider isthe sender of the first cryptogram. Thus, the authentication devicetries to decrypt the first cryptogram with the pairing key KP1 of thefirst provider record R1. Then, the authentication device 10 comparesthe result of this decryption with expected data, namely in this examplethe provider entifier 21 (ID_(SP1)) stored in the provider record R1. Ifthe decryption result does not match with the identifier ID_(SP1), thenthe authentication device process again with another provider record 35,typically with R2. Given that the comparison of the result of thedecryption (performed by the authentication device) with the secondpairing key KP2 (stored in the second provider record R2) does not matchwith the provider identifier ID_(SP2) stored in this record R2, theauthentication device concludes that the cryptogram does not come fromthe second service provider SP2. Once the authentication device willhave tested pairing data stored in the third provider record R3, thecomparison will indicate a match and the identification/authenticationwill be successfully achieved. In the case where the pairing key KP is ashared key used within a symmetric cryptographic scheme, theauthentication device 10 may also encrypt the provider identifier of aprovider record by means of the pairing key stored in this record andmay compare the result of this encryption with the first cryptogramreceived from the service provider. It should be noted that thecryptographic algorithm (or any other function) used by theauthentication device must be the same as that used by the serviceprovider in order to retrieve the same results.

Instead of using the provider identifier 21 as first data of the firstcryptogram, one can use e.g. an expected shared value, the deviceidentifier 11, a challenge or any other data that the authenticationdevice 10 knows it must retrieve and knows how to do it. Besides, firstdata is not limited to one data, but may include or be based on severaldata, among said pairing data 31.

Depending on the embodiments of the present invention, the transmissionof the authentication request 32 can be achieved according to severalways. In the case where the authentication device 10 is not providedwith a communication interface 12 for exchanging data with the serviceprovider 20, the authentication device can firstly display theauthentication request 32 (e.g. in the form of one or severalalphanumeric characters strings). Then, the user 1 enters manually thedisplayed authentication request 32 in the terminal 40, in particular inan appropriate field displayed on the computer screen by the softwareapplication 43 installed in the terminal 40 (or at the provider side).Finally, the terminal sends the entered authentication requests to therelevant service provider 20 by means of the software application 43.

According to another embodiment, the authentication request 32 could beautomatically sent to the terminal device 40 without any manualintervention of the user. Such data exchange will transit through thecommunication interfaces 12 and 42 of the authentication device 10,respectively of the terminal 40. The authentication request 32 will beforwarded by the terminal 40 to the relevant service provider 20 via thenetwork 50 and through the respective communication interfaces 42 and22. According to a further embodiment, in particular in case theauthentication device 20 refers to software application installed in acommunication device such as a smart phone or a tablet computer forinstance, the authentication request 32 can also be automatically sentfrom the authentication device 10 to the service provider 20.

The same ways as those described above can be performed in the reversedirection for receiving device authentication data 33 from the serviceprovider 20 (e.g. via a one-time code 34). In the case where theauthentication device 10 is not provided with a communication interface12 for exchanging data with the terminal 40 (or directly with theservice provider), then the OTC 34 could be displayed by the computerscreen of the terminal 40 before to be manually entered by the user 1into the authentication device 10 (via the user interface 15).

By using same pairing data and the same function (or the same algorithm)for preparing provider authentication data 33 to send to theauthentication device, this provider authentication data 33 will neverchange from one login to another. Thus, it should be useful to diversifythe messages (codes) exchanged between the service provider and theauthentication device in view to reduce piracy risks. This can beachieved by including, in the exchanged data, a first challenge whichcan be identified by the recipient. For instance, providerauthentication data 33 may comprise a first challenge in the form of arandom number (generated and added by the service provider), e.g. havinga certain number of digits. If the recipient (i.e. the authenticationdevice) knows that provider authentication data comprises or has beenmixed with a random number and knows how to identify this random number,therefore it will be able to extract the first challenge from theprovider authentication data. The first challenge can be added to thefirst data prior to the encryption by the pairing key KP. At thereception by the authentication device, the decryption of the cryptogramby the pairing key will thus obtain the combination of the first dataand the challenge. The challenge is then extracted to obtain the firstdata.

By including such a first challenge in provider authentication data,data sent by the service provider to the authentication device typicallycorrespond to the so-called one-time code (OTC) 34. One-time codesand/or one-time passwords avoid replaying the same code/password,reducing the chances of success of a “man in the middle” attack,preventing phishing and any cloning of the authentication device.

The first challenge can be already part of pairing data, or can beconsidered as being part of such data in case it can be retrieved fromone or some pairing data or from a shared protocol, for instance basedonto a counter synchronized both at the sender and at the recipient. Inthis case, provider authentication data 33 could comprise only aprovider signature based on the first challenge.

According to another embodiment, the step of preparing and sendingdevice authentication data can be achieved under certain conditionsonly. For instance, this step can be performed if the verification, bythe authentication device, of provider authentication data by means ofpairing data stored by the authentication device provides a positiveoutcome.

In the case where the provider authentication data is a signed providermessage which comprises the provider identifier 21 and the digitalsignature of this provider applied to its provider identifier (by meansof a one-way function and the pairing key KP, so that e.g. the providermessage={ID_(SP); [hash(ID_(SP))]_(KP)}), then the authentication device10 must verify the authenticity of the message received from the serviceprovider after having identified the provider record 35 to which theprovider identifier refers. Identifying the provider record can beperformed by sequentially comparing the provider identifier of thereceived message with each identifier of the pairing data stored in theauthentication device until a match. Then, verifying the authenticity ofthe message received from the service provider can be achieved by:

-   -   decrypting the provider digital signature by means of the        pairing key KP of the identified provider record 35,    -   comparing the result of this decryption with a digest calculated        (by the authentication device) by means of the one-way function        applied onto the provider identifier 21. If there is a match,        the service provider has been successfully authenticated by the        authentication device.

Instead of applying the signature onto the provider identifier 21 in theaforementioned signed provider message, one could applying the signatureonto another pairing data such as a shared value, the device identifier,the first challenge or a second challenge as disclosed later.

In a variant, the pairing key KP can be determined both by the serviceprovider and the authentication device instead of being merely retrievedfrom a memory by each of these entities, e.g. by extracting it from thedatabase 28, or from a provider record 35. For that purpose, the serviceprovider can comprise a provider key Kpp which is the result of aone-way function of a root key KR parameterized by the provideridentifier ID_(SP) 21. In other words, one can write: Kpp=f₁(KR;ID_(SP)). The root key KR has been previously stored in theauthentication device, for instance in the secured memory 16 during themanufacturing of the authentication device or at least before it isdelivered to the user 1 (thus before the first use of the authenticationdevice by the user).

The pairing key KP is calculated by the service provider 20 as being theresult of a one-way function of the provider key Kpp parameterized bythe authentication device identifier 11, so that KP=f₂(Kpp; I D_(AD)).

From the other side, the (same) pairing key KP is calculated by theauthentication device 10 as being the result of a one-way function ofthe root key KR parameterized by the provider identifier 21 and by thedevice identifier 11, so that KP=f₃(KR; ID_(SP); ID_(AD)). The firstone-way function f₁ can be identical or different from the secondone-way function f₂. The third one-way function f₃ results from acombination of the two other functions. Indeed, given that theauthentication device 10 knows the root key KR which has been used bythe service provider for determining its provider key Kpp, therefore theauthentication device is also able to calculate this provider keyKpp=f₁(KR; ID_(SP)), because it already knows the provider identifier ID_(SP). Then, by means of the provider key Kpp and its own deviceidentifier ID_(AD), the authentication device is further able tocalculate the pairing key KP=f₂(Kpp; ID_(AD)). Of course, the serviceprovider and the authentication device have to use the appropriatefunctions f₁, f₂, f₃ (which can be shared in advance). Advantageously,data of messages exchanged between the authentication device and theservice provider can be encrypted/decrypted by means of a pairing key KPwhich is not merely extracted from a memory, but which has to be firstlydetermined by each entity before handling these messages. This way ofdoing allows increasing the security of the data exchange system.

According to another variant, the pairing key KP could be used fordetermining a session key KS which could be then used forencrypting/decrypting data (or messages) sent between the serviceprovider and the authentication device 10. In other words, the pairingkey KP could be regarded as being an intermediated pairing key and thesession key KS as being the (final) pairing key. Therefore, oncedetermined, the session key KS could be used as encryption key both inthe provider authentication data 33 and in the device authenticationdata 36, instead of the pairing key. The session key KS can bedetermined, separately, by the sender and by the recipient, on the basisof shared data such as the pairing key KP, a shared function and achallenge for instance. For example, the session key KS could bedetermined (at each side) as being the result of a XOR function havingboth the pairing key KP and a challenge CH as operands, so that KS=(KPXOR CH). Such a challenge could be the second challenge. Of courseanother function or even a synchronized counter could be also usedinstead of such a logical function (logical operation).

According to another variant, the pairing key KP may be also determined,separately by the sender and by the recipient, on the basis of aDiffie-Hellman key exchange. To this end, the authentication device 10and the service provider 20 comprise: a shared value, the provideridentifier 21 and the device identifier 11 as pairing data 31. Thepairing key KP can be determined at each side by raising said sharedvalue to the power of the product of the provider identifier 21 and thedevice identifier 11.

In variant:

-   -   the shared value can be the root key KR,    -   the authentication device 10 comprises a device key Kpd (stored        in its secured memory 16) which is the result of the root key KR        raised to the power of the device identifier ID_(AD), so that        Kpd=^(IDAD),    -   the service provider 20 comprises a provider key Kpp which is        the result of said root key KR raised to the power of provider        identifier ID_(SP), so that Kpp=KR^(IDSP).    -   the pairing key KP can be determined at the authentication        device 10 by raising the device key Kpd to the power of the        provider identifier I D_(SP), so that        KP=Kpd^(IDSP)=KR^(IDAD′IDSP),    -   this pairing key KP can be determined at the service provider 20        by raising the provider key Kpp to the power of the device        identifier ID_(AD), so that KP=Kpp^(IDAD)=KR^(IDSP′IDAD),

This way of doing can be also be improved by using a modulo functionapplied to Kpp and Kpd, as well known by the person skilled in the art.

Besides, it could be useful to normalize the length of the provideridentifier 21 and/or the length of the device identifier 11 to a certainnumber of digits or bits defined as a standard for all service providers20. To this end, the latters (and/or each authentication device) couldbe provided with a function will allow e.g. to extend the length of theidentifier to a predefined length before using this identifier infurther operations.

In a further variant, the pairing key KP could be regarded as beingeither a private key or a public key in the case where these two lastkeys form a pair of keys, according to an asymmetric encryption scheme.In such a scheme, one should consider whether the pairing key KP is usedfor encrypting data by a sender or whether it is used for decryptingdata by the recipient. Indeed, in such a scheme:

-   -   the pairing key KP used by the authentication device 10 for        encrypting data is a public provider key Kup, whereas if this        pairing key KP is used by the device 10 for decrypting data,        then KP will be considered as a device key Kpd, in particular as        a private device key;    -   similarly, the pairing key KP used by the service provider 20        for encrypting data is a public device key Kud, whereas the        pairing key KP used by the service provider 20 for decrypting        data is a provider key Kpp, in particular a private provider        key.

Accordingly, (Kpd; Kud) form a first pair of keys belonging to theauthentication device 10, and (Kpp; Kup) form a second pair of keysbelonging to the service provider 20. Therefore, the aforementioned datacan be exchanged in an encrypted form between these two entities.

According to a further embodiment, the authentication request 32 canfurther comprise a second challenge generated by the sender, namely bythe authentication device 10, and identifiable by the recipient, namelyby the service provider 20. The use of this second challenge could besimilar to the use of the first challenge described above. In bothcases, the sought purpose is to avoid replaying same data in themessages exchanged between the service provider and authenticationdevice, by generating one-time requests 32, one-time codes 34 andone-time passwords 37. Accordingly, such a second challenge could bealso included in the provider authentication data 33, for instance asbeing data used by the service provider for generating its digitalsignature.

Whatever the embodiment, the above-mentioned method can be regarded asreferring to a user login phase for login the user 1 with one of theservice providers 20 recognized by the authentication device 10.Accordingly, the present method can comprises an account registrationphase performed by each user 1 wanting to join a new service provider20. It should be understood that the account registration phase isperformed only one time with each service provider 20, before the userperforms for the first time the user login phase with this serviceprovider.

According to one embodiment, the account registration phase comprisesthe steps of:

-   -   sending the device identifier 11 from the authentication device        10 to the service provider 20,    -   generating, by the service provider 20, a provider message        comprising at least the provider identifier 21 and a provider        signature of said at least provider identifier 21, said        signature being encrypted by a first key which can be a public        provider key Kup or a pairing key KP determined on the basis of        a shared protocol,    -   sending said provider message to the authentication device 10,    -   verifying, at the authentication device 10, that said provider        message is authentic and in positive outcome, then    -   adding a provider record 35 assigned to the service provider 20        and storing at least a part of data comprised in said provider        message as pairing data 31 in the authentication device 10; data        stored as pairing data can be typically the provider identifier        21 and the pairing key KP,    -   preparing, at the authentication device 10, a response        comprising at least the device identifier 11 and a device        signature of said at least device identifier 11, said signature        being encrypted by a second key which can be a public device key        Kud or the shared pairing key KP, then sending this response to        the service provider 20,    -   verifying, at the service provider 20, that said response is        authentic and in positive outcome, then creating in a database        28 of the service provider 20 a user account 25 for storing said        pairing data 31, typically the device identifier 11 and the        shared pairing key KP.

The provider digital signature has been determined by calculating afirst digest (e.g. by using the provider identifier as input of aone-way function), then by encrypting this first digest with the pairingkey KP.

Verifying that the provider message is authentic is performed byverifying the authenticity of the provider digital signature. To thisend, the authentication device 10 performs the steps of:

-   -   calculating a second digest of said signing data (included in        the provider message) by means of the above-mentioned one-way        function,    -   decrypting the provider signature by means of the first key;    -   comparing the second digest with the first digest, and if the        comparison provides a match then performing the next steps.

In the case where the first key is a public key, this public key can beauthenticated by means of a digital certificate containing this publickey and a signature of a trust certificate authority.

Verifying that the response received by the service provider isauthentic can be performed by the same mechanism as that performed bythe authentication device for verifying that the provider message (inparticular the provider signature) is authentic.

The one-way functions cited in the present description could refertypically to the cryptographic hash functions SHA-1, SHA-2 or SHA-3.However, the one-way functions used in the invention are not limited tothese examples.

Advantageously, owing the present invention, the user can use the sameauthentication device 10 for accessing to services of several serviceproviders 20. For the user, the login data (user login and password)required to access to service providers appears as being always the samealthough it is not the case since the task of the authentication deviceof the present invention is to retrieve the appropriate authenticationdata (keys, passwords or user logins) relating to each service provider.Accordingly, login operations are greatly simplified for the user sincehe has the feeling to have a universal password (and a universal userID). In the same time, the invention provides a fully secure solutionfor performing mutual authentications each time the user want to haveaccess to a service provider which requires entering a user ID and therelated password. Thus, the authentication device is able toauthenticate one service provider (among several service providers) andthe service provider is able to authenticate the user, making sure thereare no clones or replays of login sessions.

Moreover, by providing the authentication device with a communicationinterface for exchanging data with the service provider (eitherdirectly, or via a terminal), the use of the present invention becomeseven easier for the user, since all data exchange are automated. Theauthentication device can store a large number of provider records 35and therefore is able to give the user access to many service providersanywhere, in a really easy manner.

Besides, the implementation of the present invention is also very easy,in particular within a home environment when the user has to connect tothe service provider via a personal computer or any similar device(tablet computer, personal digital assistant, laptop, etc . . . ). Forinstance, the login page of the Internet site of the service providermust be merely adapted to suggest to the user a login via theauthentication device of the invention. The user could have just toselect the appropriate login means and then the software application(installed in the computer at the user side or at the server side) willbe able to process the authentication according to the method of thepresent invention. Moreover, by using the NFC technology (or any otherwireless short range connection), data exchange between the terminal 40and the authentication device 10 are secured enough, in particularwithin a home environment.

The subject-matter of the present invention also refers to theauthentication device 10 used for performing the above-mentioned method.In particular the present invention refers to an authentication device10 for authenticating a user 1 to a service provider 20, among aplurality of service providers 20, comprising:

-   -   a unique device identifier 11,    -   a non-volatile secured memory 16 for storing secret and/or        shared data,    -   a user interface 15 for user data input,    -   a display 14,    -   a crypto-processor for performing cryptographic and logical        operations and for managing functions and all components of the        authentication device 10.

According to the invention, this authentication device 10 ischaracterized in that:

-   -   the memory 16 is organized for storing specific data relating to        a plurality of service providers 20, and    -   the crypto-processor 17 is able (i.e. programmed) to process        with said plurality of service providers 20 in view of        retrieving data relating to each of these service providers and        processing them in a distinct manner.

In particular, the memory 16 is organized for efficiently retrievingdata referring to several service providers. This can be achieved byordering data relating to each of these service providers in specificrecords, in particular in the provider records 35 shown in FIG. 3.

According to one embodiment, the authentication device 10 furthercomprises a communication interface 12 for data exchange. This interfacecan be a wireless short range communication interface, such as aninfrared or Bluetooth interface, preferably a NFC interface(Near-Field-Communication). Alternatively, the communication interfacecan be a wire interface, e.g. an USB port.

According to a preferred embodiment, the user interface 15 is a keypadprovided with several buttons, typically buttons corresponding tonumbers 0-9 and at least one so-called “enter” or “OK” button, one“clear” button and one “on/off” button. Of course, other buttons such asa decimal point or alphabetic buttons could be also included. Such akeypad is typically used by the user for entering its user login andcodes provided by the service provider. However, it could be also usedby the user for entering a personal identification number (PIN code),preferably just after the activation of the authentication device forproviding its full access. According to another embodiment, the userinterface 15 could be a biometric sensor such as a fingerprints sensor,a micro-camera or a voice sensor for acquiring biometric data (i.e.features) of the user (such as fingerprints, an iris picture, the shapeof the user's face, hands or veins geometry, user's voice). In thiscase, such a biometric sensor would be only used for authenticating theuser to the authentication device 10.

Preferably, the device identifier 11 will be printed onto theauthentication device 10 so that there is no risk for the user 1 toloose it. Still preferably, the device identifier 11 is stored in thememory 16 of the authentication device.

According to a preferred embodiment, the authentication device 10 is asmart card as schematically shown in FIG. 2. The memory 16 and thecrypto-processor 17 can be embedded in a single chip set, for instancein a monolithic chip, so that data stored in the authentication deviceare physically protected against any malicious person. Thecrypto-processor comprises cryptographic computing capabilities tocalculate passwords and process numbers for verifying the validity of anexisting account (in reference to provider records) or for adding a newaccount (provider record).

According to another embodiment, the authentication device can be in theform of software application that could run securely on hardware (PC, orany portable computing or communication device).

Advantageously, the authentication device 10 of the present invention isnot only able to manage several accounts (provider records) of serviceproviders, but it is also able to develop its capabilities by adding newaccounts providing access to new service providers. This becomespossible owing to the account registration phase which has been alreadydisclosed above. Inversely, the user should be also able to cancelaccounts (provider records) for which he has no longer interest.

Still advantageously, by providing the authentication device 10 in theform of a smart card with a display 14 and a user interface 15 forinputting data, such a device 10 becomes autonomous (self-governing) anddoes not require any more to be inserted into a card reader before to beused for authentication purposes. Accordingly, all service providerswill find a predominant economic interest and both the user and theservice providers will be winners.

1. (canceled)
 2. A method for authenticating a user to a serviceprovider using an authentication device identified by a deviceidentifier, said method comprising a prior registration phase toregister the authentication device with the service provider by:creating a new user account at the service provider; and performing apairing process for providing both the authentication device and theservice provider with common pairing data.
 3. The method of claim 2,wherein said pairing data comprise at least one of pairing keys, shareddata, functions and algorithms.
 4. The method of claim 2, wherein saidpairing data are stored in a secure memory of the authentication device.5. The method of claim 2, wherein said pairing data are stored at theservice provider in a database.
 6. The method of claim 5, wherein saidpairing data being stored at the service provider in the user accountcreated in the database of the service provider.
 7. The method of claim2, further comprising: sending the device identifier from theauthentication device to the service provider; generating, by theservice provider, a provider message enabling to derive at least aprovider identifier; sending the provider message to the authenticationdevice; preparing at the authentication device a response enabling toauthenticate the authentication device; and sending the response to theservice provider.